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Abstract 

Transactions  in  real-time  database  systems  should 
be  scheduled  considering  both  data  consistency  and  tim¬ 
ing  constraints.  In  addition,  a  real-time  database  must 
adapt  to  changes  in  the  operating  environment  and  guar¬ 
antee  the  completion  of  critical  tasks.  The  effects  of 
scheduling  decisions  and  concurrency  control  mecha¬ 
nisms  for  real-time  database  systems  have  typically  been 
demonstrated  in  a  simulated  environment.  In  this  paper 
we  present  a  functional  real-time  relational  database 
manager,  called  MRDB,  which  provides  an  operational 
platform  for  research  in  real-time  database  issues.  Cur¬ 
rent  research  issues  involving  the  development  of  run¬ 
time  estimates  for  use  in  scheduling  decisions,  temporal 
consistency  characteristics,  and  our  efforts  in  using  these 
are  also  discussed. 


1.  Introduction 

Real-time  database  systems  have  (at  least  some) 
transactions  with  explicit  timing  constraints  such  as 
deadlines. The  correctness  of  the  system  depends  not 
only  on  the  logical  results  but  also  on  the  time  within 
which  the  results  are  produced.  In  a  real-time  database 
system,  transactions  must  be  scheduled  in  such  a  way 
that  they  can  be  completed  before  their  corresponding 
deadlines  expire.  Real-time  databases  are  essential  for 
applications  that  are  both  data  intensive  and  subject  to 
real-time  constraints,  such  as  defense  systems,  industrial 
automation,  aerospace  and  network  management 
[Son88].  Appropriate  methods  and  techniques  for 
designing  and  implementing  database  systems  that  take 
timing  constraints  into  account  are  playing  an  ever 
increasing  role  in  determining  the  success  or  failure  of 
real-time  systems.  In  recent  workshops  [IEEE93, 
RTA93],  developers  of  real-time  systems  have  pointed  to 
the  need  for  basic  research  in  database  systems  that  sat¬ 
isfy  timing  constraint  requirements  in  collecting,  updat¬ 
ing,  and  retrieving  shared  data. 

Real-time  database  systems  have  many  similari¬ 
ties  with  conventional  database  management  systems 
and  with  conventional  real-time  systems.  They  fall  in  the 
intersection  between  the  two  types  of  systems,  and  is  not 
quite  the  same  as  either  one  of  the  two.  Real-time  data¬ 
base  systems  must  process  transactions  and  guarantee 
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that  database  consistency  is  not  violated  just  as  in  a  con¬ 
ventional  database  system.  Conventional  database  sys¬ 
tems,  however,  do  not  stress  the  notion  of  time 
constraints  or  deadlines  with  respect  to  transactions. 
Individual  temporal  constraints  are  not  taken  into 
account  when  making  scheduling  decisions.  The  perfor¬ 
mance  goal  for  conventional  database  systems  is  usually 
expressed  in  terms  of  minimizing  average  response  times 
instead  of  constraints  on  individual  transactions. 

Conventional  real-time  systems  do  take  transac¬ 
tion  temporal  specifications  into  account,  but  ignore  data 
consistency  issues.  Real-time  systems  also  typically 
work  with  processes  which  have  predictable  resource 
requirements,  to  include  data  requirements.  Database 
systems  tend  to  make  unpredictable  data  accesses.  This 
exasperates  the  scheduling  problem,  and  highlights 
another  difference  between  a  conventional  real-time  sys¬ 
tem  and  a  real-time  database  system.  The  conventional 
real-time  system  attempts  to  ensure  that  no  temporal  con¬ 
straints  are  violated.  In  real-time  database  systems,  it  is 
impossible  to  guarantee  all  temporal  constraints  because 
of  the  unpredictable  data  accesses,  so  the  system  must 
strive  to  minimize  the  number  of  constraints  which  are 
violated  [Abb92,  Kim93,  Son93]. 

State-of-the-art  database  systems  are  typically  not 
used  in  real-time  applications  due  to  two  major  inade¬ 
quacies:  lack  of  predictability  and  poor  performance 
[Son90].  Current  database  systems  do  not  schedule  their 
transactions  to  meet  response  requirements  and  they 
commonly  lock  data  objects  to  assure  the  consistency  of 
the  database.  The  problem  is  that  locks  and  time-driven 
scheduling  are  incompatible.  Low  priority  transactions 
can  and  will  block  higher  priority  transactions  leading  to 
priority  inversions  and  response  requirement  failures. 
Recently,  a  considerable  research  effort  has  been  focused 
on  real-time  database  scheduling  and  data  consistency 
control  mechanisms.  The  integration  of  the  two  in  real¬ 
time  database  systems  is  not  trivial,  because  all  existing 
concurrency  control  methods  synchronize  concurrent 
data  accesses  by  the  combination  of  two  measures;  block 
and  rollback,  both  of  which  create  barriers  for  time-crit¬ 
ical  scheduling.  Concurrency  control  mechanisms  such 
as  Priority  inheritance.  Priority  ceiling  protocol,  Opti¬ 
mistic  protocols,  and  Conditional  restart  have  been  stud¬ 
ied  and  implemented  in  an  attempt  to  manage  the 
integration  of  real-time  scheduling  and  data  consistency 
requirements  in  real-time  databases  [Abb89,  Car89, 
Har90,  Hua90,  Sha91].  They  are  typically  compatible 
with  time-driven  scheduling,  and  meet  both  the  required 
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system  response  predictability  and  temporal  consistency. 

The  design  and  evaluation  of  real-time  database 
systems  presents  challenging  problems.  In  this  paper  we 
describe  a  functional  multi-user  real-time  relational 
database  system  (MRDB),  which  we  have  developed  for 
exploring  real-time  database  issues.  In  addition,  we 
examine  issues  involving  the  development  of  credible 
run-time  estimates  for  use  in  real-time  database  schedul¬ 
ing  decisions,  the  integration  of  data  and  temporal  func¬ 
tionality,  and  the  use  of  temporal  consistency 
specifications  in  performing  database  operations.  The 
remainder  of  the  paper  is  organized  as  follows.  Section 
2  provides  the  reader  with  information  on  temporal  con¬ 
straint  issues  and  temporal  functionality  which  were 
sought  in  the  design  of  MRDB.  Section  3  describes  our 
multi-user  real-time  database  server  and  the  environment 
in  which  it  operates.  Section  4  presents  real-time  sched¬ 
uling  policies  that  are  implemented  in  MRDB,  our  deri¬ 
vation  and  use  of  run-time  estimates  and  initial  run-time 
performance  measurements.  Finally,  Section  5  summa¬ 
rizes  the  paper  and  the  areas  of  future  work. 


2.  Temporal  Functionality  and  Issues 

One  of  the  major  goals  in  designing  real-time 
database  systems  is  to  meet  timing  constraints.  It  is  also 
one  of  the  major  problems  when  designing  a  real-time 
scheduler  which  attempts  to  minimize  the  probability  of 
transactions  failing  to  meet  their  respective  deadlines. 
Various  approaches  have  been  investigated  to  develop 
database  systems  to  achieve  this  goal.  The  designers  of 
CASE-DB  [Ozso90]  used  an  iterative  evaluation  tech¬ 
nique  coupled  with  a  risk  probability  attribute  in  an 
attempt  to  provide  as  much  information  as  possible 
within  a  given  deadline.  The  priority  ceiling  protocol, 
which  was  initially  developed  as  a  task  scheduling  proto¬ 
col  for  real-time  operating  systems,  has  been  extended 
for  use  in  RTDBS  [Sha91].  It  is  based  on  a  two-phase 
locking  protocol  and  employs  blocking,  versus  rollback, 
in  an  attempt  to  minimize  the  number  of  transactions  that 
fail  to  meet  their  deadline.  Protocols  to  schedule  real¬ 
time  transactions  using  the  concept  of  dynamically 
adjusting  the  serialization  order  have  been  developed 
and  evaluated  [Lee93,  Lin90,  Son92]. 

Those  approaches  attempt  to  make  scheduling 
decisions  based  mainly  on  transaction  attributes  such  as 
priority,  release  time  and  deadline.  These  transaction 
characteristics  are  critical  pieces  in  the  scheduling  puz¬ 
zle,  but  they  are  not  the  only  attributes  available  for  use 
in  solving  the  problem.  One  key  attribute  absent  from 
most  scheduling  decisions  is  a  viable  transaction  run¬ 
time  estimate.  Numerous  research  efforts  have  explored 
the  possibility  of  using  run-time  estimates  in  the  sched¬ 
uling  decision  process.  Run-time  estimates  have  been 
used  in  workload  policies,  priority  assignment  policies, 
conflict  resolution  policies  and  10  scheduling  policies. 
These  run-time  estimates  have  typically  been  model- 
driven.  The  results  derived  have  shown  that  run-time 
estimates  are  a  credible  option  for  use  in  scheduling  deci¬ 
sions.  However,  the  derivation  and  use  of  run-time  esti¬ 
mates  in  a  functional  real-time  database  has  not  been 
explored  extensively.  Schedulers  which  do  not  incorpo¬ 
rate  run-time  estimates  into  account  are  failing  to  use  a 


key  attribute  which  can  simplify  the  scheduling  decision. 
Scheduling  decisions  which  do  not  take  computation 
requirements  into  account  allow  such  occurrences  as 
processor  time  to  be  expended  upon  transactions  which 
cannot  meet  their  deadlines. 

If  the  real-time  database  scheduler  can  be  pro¬ 
vided  with  an  estimate  of  transaction  execution  time,  that 
information  can  be  used  in  determining  which  transac¬ 
tion  is  closest  to  missing  a  deadline,  and  hence  should  be 
given  higher  priority,  or  which  transaction  can  be 
delayed  without  risking  violation  of  their  timing  con¬ 
straints.  In  addition,  run-time  estimates  can  be  used  by 
the  scheduler  to  initially  screen  transactions  to  determine 
eligibility.  All  transactions  with  feasible  deadlines 
(release  time  plus  run-time  estimate  is  less  than  deadline) 
remain  in  the  system  and  are  eligible  for  service,  while 
all  ineligible  transactions  are  aborted. 

We  sought  predictability  and  accuracy  in  explor¬ 
ing  the  feasibility  of  using  run-time  estimates  in  schedul¬ 
ing  decisions  for  real-time  database  systems.  Without  a 
predictable  and  accurate  run-time  estimate,  little  can  be 
gained  in  the  scheduling  decision  cycle,  while  leaving 
the  system  susceptible  to  unpredictable  behavior.  That  is 
not  to  say  that  run-time  estimates  have  to  be  correct 
100%  of  the  time,  since  the  typical  real-time  database 
performance  goal  is  usually  expressed  in  terms  of  mini¬ 
mizing  missed  deadlines,  not  guaranteeing  no  missed 
deadlines.  However,  because  of  their  serious  impact  on 
scheduling  decisions,  the  run-time  estimates  must  be 
both  predictable  and  reliable  [Kim93]. 

Often  a  significant  portion  of  a  real-time  database 
is  highly  perishable  in  the  sense  that  it  has  value  only  if 
it  is  used  in  time.  In  addition  to  deadlines,  therefore, 
other  kinds  of  temporal  information  should  be  associated 
with  data  as  well  as  transactions  in  a  real-time  database 
system.  For  example,  each  sensor  input  could  be 
indexed  by  the  time  at  which  it  was  taken.  Once  entered 
in  the  database,  data  may  become  out-of-date  if  it  is  not 
updated  within  a  certain  period  of  time.  To  quantify  this 
notion  of  age ,  data  may  be  associated  with  a  valid  inter¬ 
val.  The  valid  interval  indicates  the  time  interval  after 
the  most  recent  updating  of  a  data  object  during  which  a 
transaction  may  access  it  with  100%  degree  of  accuracy. 
What  occurs  when  a  transaction  attempts  to  access  a  data 
object  outside  of  its  valid  interval  is  dependent  upon  the 
semantics  of  data  objects  and  the  particular  implementa¬ 
tion.  For  some  data  objects,  for  instance,  reading  it  out 
of  its  valid  interval  would  result  in  0%  accurate  values. 
In  general,  each  data  object  can  be  associated  with  a 
validity  curve  that  represents  its  degree  of  validity  with 
respect  to  the  time  elapsed  after  the  data  object  was  last 
modified.  The  system  can  compute  the  validity  of  data 
objects  at  the  given  time,  provided  the  time  of  last  mod¬ 
ification  and  its  validity  curve  [Liu88,  Son91]. 

A  real-time  transaction  should  include  its  tempo¬ 
ral  consistency  requirement  which  specifies  the  validity 
of  data  values  accessed  by  the  transaction.  For  example, 
if  the  temporal  consistency  requirement  is  10,  it  indicates 
that  data  objects  accessed  by  the  transaction  cannot  be 
older  than  10  time  units  relative  to  the  start  time  of  the 
transaction.  This  temporal  consistency  requirement  can 
be  specified  as  either  hard  or  soft,  just  as  deadlines  are. 
If  it  is  hard,  an  attempt  to  read  an  invalid  data  object  (i.e., 
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out  of  its  valid  interval)  will  cause  the  transaction  to  be 
aborted. 

While  a  deadline  can  be  thought  of  as  providing  a 
time  interval  as  a  constraint  in  the  future,  temporal  con¬ 
sistency  specifies  a  temporal  window  as  a  constraint  in 
the  past.  As  long  as  the  temporal  consistency  require¬ 
ment  of  a  transaction  can  be  satisfied,  the  system  must  be 
able  to  provide  an  answer  using  available  (may  not  be 
up-to-date)  information.  The  answer  may  change  as 
valid  intervals  change  with  time.  In  a  distributed  data¬ 
base  system,  sensor  readings  may  not  be  reflected  to  the 
database  at  the  same  time,  and  may  not  be  reflected  con¬ 
sistently  due  to  the  delays  in  processing  and  communica¬ 
tion.  A  temporal  data  model  for  real-time  database 
systems  must  therefore  be  able  to  accommodate  the 
information  that  is  partial  and  out-of-date.  One  of  the 
aspects  that  distinguishes  a  temporal  data  model  for  a 
real-time  database  systems  from  that  of  conventional 
database  systems  is  that  values  in  a  real-time  database 
system  are  not  necessarily  correct  all  the  time,  and  hence 
the  system  must  be  selective  in  interpreting  data  values. 

Another  design  goal  of  real-time  database  systems 
is  to  enhance  the  temporal  functionality  associated  with 
the  data  stored  within  the  database.  Temporal  informa¬ 
tion  has  been  stored  in  conventional  databases  for  many 
years;  accounting  and  payroll  systems  are  typical  exam¬ 
ples.  In  these  systems  the  attributes  involving  time  are 
manipulated  solely  by  the  application  programs.  None 
of  these  systems  interpret  temporal  domains  when  deriv¬ 
ing  new  relations  or  extracting  data.  Most  conventional 
database  systems  represent  the  state  of  an  enterprise  at  a 
single  moment  of  time.  Although  the  contents  of  the 
database  continue  to  change  as  new  information  is 
added,  these  changes  have  typically  been  viewed  as 
modifications  to  the  state,  with  the  old,  out-of-date  data 
being  deleted  from  the  database.  The  new  state  also  does 
not  necessarily  reflect  the  current  status  of  the  real  world, 
since  changes  to  the  database  always  lag  behind  changes 
in  the  real  world  [Sno87]. 


3.  Implementation  of  MRDB 

MRDB  is  a  functionally  complete  relational  data¬ 
base  manager.  It  offers  not  only  a  functionally  complete 
set  of  relational  operators  such  as  project,  select,  join, 
union  and  set  difference ,  and  aggregate  operators  such  as 
max,  min,  avg,  count  and  sum,  but  also  other  necessary 
relational  operators  such  as  create,  insert,  update,  delete, 
rename,  compress ,  extract,  import,  export,  sort ,  and 
print.  These  operators  give  the  user  a  fair  amount  of  rela¬ 
tional  power  and  convenience  for  managing  the  data¬ 
base. 

MRDB  is  designed  along  the  traditional  client- 
server  paradigm.  It  has  a  multiple-threaded  server  that  is 
capable  of  accepting  MRDB  commands  from  multiple 
client  sites.  MRDB  was  designed  with  the  goal  of  pro¬ 
viding  a  temporal  platform  for  conducting  research  on 
real-time  database  issues.  It  allow  us  to  analyze  real¬ 
time  database  mechanisms  in  an  operational  environ¬ 
ment.  This  is  a  major  and  natural  step  forward  from  per¬ 
formance  analysis  conducted  in  a  simulated  real-time 
database  environment.  Simulated  environments  are  not 


a  substitute  for  functional  systems.  They  fail  to  account 
for  all  factors  found  in  an  operational  system,  and  tend  to 
be  more  subjective  in  the  sense  that  system  parameters 
can  be  readily  modified.  An  operational  system  cannot 
be  modified  to  fit  the  real-time  mechanism  being  ana¬ 
lyzed.  The  results  derived  from  an  operational  real-time 
database  system  provide  us  with  a  set  of  more  realistic 
performance  measurements. 

The  MRDB  server  is  the  heart  of  the  database 
management  system.  It  is  responsible  for  receiving  and 
acting  on  requests  from  multiple  clients,  and  returning 
desired  information  to  the  clients.  The  server  contains 
an  infinite  loop  that  accepts  high-level  database  requests 
(e.g.,  create,  union,  insert)  from  multiple  clients.  The 
requests  come  in  as  packets.  The  MRDB  system  pro¬ 
vides  two  different  types  of  packets:  call  packets  and 
return  packets.  The  call  packet  is  created  by  the  client 
and  is  the  database  transaction.  The  call  packet  contains 
all  the  information  that  the  server  needs  to  carry  out  the 
desired  database  access  operation,  to  include  the  timing 
constraint  and  temporal  consistency  specifications  asso¬ 
ciated  with  the  transaction.  Clients  are  able  to  specify 
timing  constraints  and  temporal  consistency  specifica¬ 
tions  for  each  transaction  submitted  to  the  server  thread. 
A  different  timing  constraint  can  be  specified  for  each 
transaction  submitted,  or  the  client  can  use  the  default 
timing  constraint  previously  established.  The  MRDB  cli¬ 
ent  thread  passes  the  call  packet  forward  to  the  MRDB 
server.  The  server  performs  some  preprocessing  and  then 
forwards  the  packet  to  the  MRDB  scheduler. 

The  MRDB  scheduler  uses  a  run-time  estimate 
evaluation  technique  to  determine  if  the  system  can  pro¬ 
vide  the  client  with  the  information  requested  within  the 
timing  constraint  specified.  The  MRDB  server  will  spin¬ 
off  a  separate  MRDB  thread  to  execute  the  transaction  if 
the  scheduler  makes  the  determination  that  a  transaction 
can  be  computed  within  the  given  deadline.  No  thread 
spun-off  will  occur  if  the  MRDB  scheduler  determines 
that  the  transaction  cannot  be  completed  within  the  spec¬ 
ified  timing  constraint.  The  thread  will  execute  until 
completion  and  then  forward  the  call  packet  back  to  the 
client.  The  client  thread  will  process  the  return  packet 
accordingly.  A  transaction  is  not  preempted  by  the 
MRDB  thread  even  if  the  determination  has  been  made 
that  a  deadline  is  missed.  The  fact  that  a  transaction  has 
missed  its  deadline  will  be  reported  to  the  client,  along 
with  the  results  of  the  transaction. 

MRDB  also  associates  a  temporal  ‘valid  time ’ 
attribute  with  each  relation  created  in  MRDB.  This  is 
inherent  to  the  system,  requiring  no  client  involvement. 
The  temporal  attribute  is  attached  to  each  tuple  of  a  rela¬ 
tion  and  is  comparable  to  a  timestamp  that  represents  the 
valid  time  that  the  stored  information  models  reality.  The 
client  cannot  set  or  modify  the  values  associated  with  the 
valid  time  attribute.  However,  this  attribute  can  be 
manipulated  for  use  in  specifying  transaction  temporal 
consistency  requirements.  For  example, 

select  trk_num  from  trackfile  where  valid  time  <  1 

will  return  only  the  track  numbers  (trk_num)  of  tuples 
inserted  or  updated  in  the  database  relation  (trackfile) 
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within  the  last  second  of  the  transaction  release  time. 
Track  numbers  with  valid  time  attribute  values  older  than 
a  second  are  active  within  the  relation,  but  do  not  satisfy 
the  temporal  consistency  requirement  specified.  MRDB 
also  allows  users  of  the  system  to  manipulate  the  valid 
time  attribute  in  output  displays  and  in  creating  and 
manipulating  relations  that  are  similar  to  those  found  in 
historical  temporal  database  systems  [Sno87].  A  rela¬ 
tion  without  the  temporal  attribute  valid  time  attribute 
can  be  formed  by  projecting  or  selecting  attributes  other 
than  valid  time  into  a  new  relation.  The  MRDB  system 
will  process  such  relations  without  attaching  any  tempo¬ 
ral  meaning  to  them. 

The  MRDB  system  employs  a  strict  two-phase 
locking  (2PL)  protocol  for  concurrency  control  [Ber87]. 
The  strict  locking  protocol  was  selected  for  concurrency 
control  because  of  its  prevalence  in  commercial  applica¬ 
tions  system  and  because  of  its  desirable  characteristic  of 
being  recoverable  and  avoiding  cascaded  aborts.  Fur¬ 
thermore,  abort  can  be  implemented  by  simply  restoring 
before  images.  Numerous  conflict  resolution  policies 
such  as  High  Priority,  Priority  Inheritance,  Priority  Ceil¬ 
ing  and  Conditional  Priority  Inheritance  have  been  stud¬ 
ied  extensively  in  conjunction  with  a  locking  protocol 
environment  [Abb89,  Abb92,  Hua90,  Lin89,  Sha88, 
Sha91].  The  results  indicate  that  such  conflict  resolution 
policies  are  compatible  with  time-driven  scheduling,  and 
meet  both  the  required  goals  of  system  response  predict¬ 
ability  and  temporal  consistency.  The  area  of  conflict 
resolution  policies,  a  significant  area  with  respect  to  the 
scheduling  of  transactions  in  a  manner  which  minimizes 
missed  deadlines,  is  an  ongoing  area  of  research  within 
MRDB,  and  is  not  addressed  further  in  this  paper. 

A  MRDB  transaction  is  characterized  by  its  tim¬ 
ing  constraints  and  its  computation  requirements.  The 
timing  constraints  are  a  release  time  *r ’  and  deadline  ‘d’. 
The  release  time  is  the  time  associated  with  the  transmit¬ 
tal  of  the  transaction  by  a  client  site.  A  computation 
requirement  is  represented  by  a  run-time  estimate  ‘rte  ’ 
which  approximates  the  amount  of  computation,  IO,  and 
communication  costs  associated  with  processing  a  trans¬ 
action.  The  deadline  corresponds  to  the  client-specified 
timing  constraint. 


The  release  time  and  deadline  are  known  to  the 
MRDB  scheduler  when  a  transaction  arrives.  The  com¬ 
putation  requirements  are  calculated  based  on  the  opera¬ 
tion  being  performed  and  the  physical  characteristics  of 
the  data  involved.  This  information  is  made  available 
prior  to  the  scheduling  decision  being  made.  We  think  it 
is  viable  to  estimate  the  execution  time  of  a  transaction 
without  having  prior  knowledge  of  the  exact  data  access 
pattern  of  a  transaction. 

The  goal  of  our  system  is  to  minimize  the  number 
of  transactions  that  miss  their  deadlines,  i.e.,  that  finish 
after  time  ‘ d '.  If  transactions  can  miss  deadlines,  one 


must  address  the  issue  as  to  what  happens  to  transactions 
that  have  already  missed  their  deadlines  but  have  not  yet 
finished.  There  are  two  alternatives.  One  is  to  assume 
that  a  transaction  that  has  missed  its  deadline  can  be 
aborted.  This  may  be  reasonable  where  the  value  of  a 
transaction  is  dependent  on  the  timeliness  of  the  return 
response.  For  example,  suppose  that  a  transaction  is  sub¬ 
mitted  to  update  the  ballistic  path  of  a  projectile  based  on 
a  radar  sensing.  If  the  deadline  is  missed,  it  may  be  more 
desirable  not  to  perform  the  operation  of  updating  the 
ballistic  path,  but  instead  to  re-submit  the  update  request 
based  on  a  newer  sensor  reading.  The  conditions  that  led 
to  the  triggering  of  the  transaction  may  have  changed. 
The  initiator  of  the  transaction  may  be  better  served  if  the 
transaction  is  re-submitted. 

A  second  option  is  to  assume  that  all  transactions 
must  eventually  be  completed,  regardless  of  whether 
they  have  missed  their  deadlines.  This  may  be  a  correct 
approach  in  an  application  such  as  banking  where  a  cus¬ 
tomer  would  rather  have  his  financial  transaction  done 
late  rather  than  not  at  all.  If  the  decision  is  made  to  pro¬ 
cess  the  transaction,  there  is  still  the  issue  of  the  priority 
of  tardy  transactions  with  respect  to  other  transactions  in 
the  system.  Transactions  which  cannot  meet  their  dead¬ 
lines  could  receive  a  higher  priority  as  their  lateness 
increases,  or  they  could  be  postponed  to  a  later  more  con¬ 
venient  time. 

The  MRDB  implementation  decision  was  a  com¬ 
bination  of  the  two  approaches.  When  a  transaction 
enters  the  system,  a  determination  is  made  as  to  whether 
a  transaction  can  be  executed  within  the  temporal  con¬ 
straint  associated  with  it.  If  the  transaction  cannot  meet 
its  deadline,  it  is  aborted.  This  has  the  nice  property  of 
not  allowing  computation  time  to  be  expended  on  trans¬ 
actions  which  cannot  meet  their  deadlines,  even  with  the 
best  effort.  To  allow  such  transactions  into  the  system 
can  adversely  affect  overall  system  performance  espe¬ 
cially  during  high  load  periods.  Aborting  a  few  late 
transactions  helps  all  other  transactions  meet  their  dead¬ 
lines,  by  eliminating  the  competition  for  resources  by 
tardy  transactions.  Once  a  transaction  has  been  accepted 
for  processing,  it  is  executed  to  completion,  regardless  as 
to  whether  or  not  a  deadline  has  been  met.  This  approach 
was  adopted  as  a  means  of  validating  the  run-time  esti¬ 
mates  derived  by  the  scheduler. 

The  MRDB  system  has  been  developed  on  Sun 
workstations  under  the  Unix  operating  system.  MRDB 
is  written  in  C  and  designed  to  operate  across  a  local  area 
network,  with  multiple  client  nodes  accessing  the  cen¬ 
tralized  database  maintained  by  the  system.  MRDB  was 
designed  for  Unix  because  of  the  prevalence  of  the  oper¬ 
ating  system.  MRDB  has  the  nice  property  of  being 
readily  ported  to  other  Unix  sites  interested  in  real-time 
database  research.  An  argument  can  be  made  that  real¬ 
time  database  operations  need  to  be  coherent  with  the 
operating  system,  because  correct  functioning  and  tim¬ 
ing  behavior  of  database  control  algorithms  depend  on 
the  services  of  the  underlying  operating  system.  We 
agree  that  Unix  is  not  ideal  to  support  predictable  trans¬ 
action  processing.  We  have  found,  however,  through  our 
performance  analysis  of  MRDB,  that  dedicated 
resources  in  an  environment  such  as  above  can  provide 
reasonably  analyzable  and  meaningful  results. 
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4.ScheduIing  Policies  and  Run-Time  Estimates 

The  MRDB  scheduling  algorithms  have  three 
components:  a  policy  to  determine  which  tasks  are  eligi¬ 
ble  for  service,  a  policy  for  assigning  priorities  to  tasks, 
and  a  conflict  resolution  policy.  Only  the  first  two  poli¬ 
cies  are  explored  in  the  remainder  of  this  paper. 

4.1.  Scheduling  Policies 

The  MRDB  scheduler  is  invoked  whenever  a 
transaction  enters  the  system  or  terminates.  The  sched¬ 
uler  can  also  be  invoked  to  resolve  contention  (for  either 
the  CPU  or  data)  when  conflicts  occur  between  transac¬ 
tions.  The  first  task  of  the  scheduler  is  to  divide  the  set  of 
ready  transactions  into  two  categories,  those  transactions 
that  are  capable  of  meeting  their  temporal  constraints  (eli¬ 
gible)  and  those  that  cannot  meet  their  temporal  con¬ 
straints  (ineligible).  All  ineligible  transactions  are 
aborted  and  the  MRDB  client  is  informed  of  the  decision. 
Eligible  transactions  remain  in  the  system  and  are  eligible 
for  further  processing.  This  approach  differs  from  the 
non- tardy  policy  [Abb92]  which  accepts  transactions  that 
are  currently  not  late,  but  may  be  in  a  position  where  it  is 
physically  impossible  to  make  their  deadlines.  Only 
those  transactions  with  feasible  deadlines  are  considered 
to  be  eligible.  A  transaction  has  a  feasible  deadline  if  its 
deadline  is  less  than  or  equal  to  the  current  time  plus  its 
run-time  estimate: 


current  time  (t)  +  run-time  estimate  (rte)  <  deadline  (d) 

In  other  words,  based  on  the  run-time  estimate,  there  is 
enough  time  to  complete  the  transaction  before  its  dead¬ 
line.  This  policy  can  be  adapted  to  account  for  the  amount 
of  service  time  a  transaction  has  already  received.  The 
modified  policy  would  be  as  follows: 

current  time  (t)  +  run-time  estimate(rte)  -  p  <  deadline 

(d) 

where  lp’  equals  the  amount  of  service  time  a  transaction 
has  accumulated.  This  modified  policy  allows  transac¬ 
tions  to  be  screened  for  eligibility  during  the  course  of 
execution.  Transactions  that  have  been  blocked,  due  to 
either  data  or  CPU  contention,  could  be  re-evaluated  to 
determine  if  they  are  still  capable  of  meeting  their  tempo¬ 
ral  constraint.  Note  that  the  success  of  both  of  these  pol¬ 
icies  is  contingent  on  the  accuracy  of  the  run-time 
estimate.  Erroneous  run-time  estimates  which  over-esti¬ 
mate  the  actual  computational  requirements  will  cause 
transactions  to  be  aborted  needlessly.  Low  estimates  can 
degrade  system  performance  by  allowing  transactions, 
which  in  reality  cannot  meet  temporal  constraints,  to  com¬ 
pete  for  system  resources  among  transactions  which  are 
trying  to  meet  deadlines. 

There  are  many  ways  for  assigning  priorities  to 
real-time  tasks.  Three  policies  extensively  studied  by  ear- 
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lier  researchers  include  First  Come  First  Serve  (FCFS), 
Earliest  Deadline  (ED)  and  Least  Slack.{ LS)  [Abb92]. 
The  primary  weakness  of  FCFS  is  that  it  does  not  make 
use  of  deadline  information.  It  discriminates  against  a 
newly  arrived  task  with  an  urgent  deadline  in  favor  of  an 
older  task  which  may  not  have  such  an  urgent  deadline. 
The  ED  policy  has  shown  itself  to  be  effective  in  certain 
applications,  but  it  fails  to  take  into  account  the  run-time 
estimates.  The  LS  priority  assignment  policy  was 
adopted  for  MRDB.  The  slack  time  for  a  transaction  is 
an  estimate  of  how  long  we  can  delay  the  execution  of  a 
transaction  and  still  meet  its  deadline.  It  is  computed  by 
subtracting  the  current  time  plus  the  run-time  estimate 
from  the  deadline  of  the  transaction: 

Slack  (s)  =  deadline  (d)  -  (current  time  (t)  +  run-time 
estimate  (rte)) 

The  smaller  the  slack,  the  higher  the  priority.  A 
negative  slack  time  is  an  indication  that  it  is  physically 
impossible  for  the  transaction  to  meet  its  deadline.  This 
priority  assignment  policy  does  not  take  the  amount  of 
prior  service  time  into  account.  The  assignment  of  pri¬ 
ority  is  static,  occurring  once  when  the  transaction  enters 
the  system.  The  priority  computed  at  that  time  remains 
with  the  transaction  throughout  its  execution  life.  A  con¬ 
tinuous  LS  policy  could  be  used  which  does  take  service 
time  into  account.  The  continuous  evaluation  of  priori¬ 
ties  causes  the  LS  of  all  active  transaction  to  be  recom¬ 
puted  whenever  there  is  contention  for  processor  or  data. 
This  continuous  evaluation  can  lead  to  degraded  perfor¬ 
mance  as  shown  in  the  simple  example  of  Figure  1 .  The 
example  gives  the  parameters  for  three  transactions, 
shows  the  LS  computations  for  both  continuous  and 
static  versions,  and  plots  their  CPU  usage  based  on  those 


priority  assignments.  The  problem  of  continuous  LS  is 
displayed  with  the  arrival  of  transaction  T3  at  time  2.5. 
The  arrival  of  T3  causes  the  priority  of  T2  to  become 
higher  than  Tj,  resulting  in  T2  gaining  control  of  the 
CPU,  and  T j  being  blocked.  This  causes  all  three  trans¬ 
actions  to  miss  their  deadlines.  The  static  LS  version 
allows  all  three  to  meet  their  deadlines. 

A  negative  slack  time  could  occur  if  a  transaction 
has  already  missed  its  deadline  or  is  about  to  miss  its 
deadline.  The  possibility  of  a  negative  slack  time  does 
not  exist  if  a  feasible  deadline  eligibility  screening  policy 
is  implemented,  and  the  LS  priority  assignment  policy  is 
static.  The  initial  screening  conducted  to  determine  eli¬ 
gibility  will  eliminate  any  transaction  which  cannot 
physically  meet  their  deadlines  and  the  static  LS  priority 
will  prevent  the  slack  associated  with  an  eligible  transac¬ 
tion  from  ever  becoming  negative.  The  current  MRDB 
version  uses  static  LS  as  the  means  of  assigning  priorities 
to  transactions  for  scheduling,  in  an  attempt  to  expedite 
those  transactions  which  can  least  afford  to  be  delayed. 


4.2.  Run-Time  Estimates 

Conventional  real-time  systems  typically  deal 
with  processes  that  have  predictable  resource  require¬ 
ments.  These  predictable  requirements  allow  for  a  static 
evaluation  of  computation  costs.  Real-time  databases 
normally  deal  with  transactions  which  have  unpredict¬ 
able  resource  requirements.  The  random  nature  of  such 
data  accesses  complicates  the  scheduling  process  in  real¬ 
time  database  systems.  A  considerable  amount  of 
research  effort  has  been  focused  on  real-time  database 
scheduling  issues  and  the  use  of  run-time  estimates.  The 
use  of  run-time  estimates  in  scheduling  decisions  have 
been  examined  in  workload  screening,  priority  assign- 
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Figure  2.  Attributes  of  the  track  relation 
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ment,  conflict  resolution  and  IO  scheduling  policies.  The 
results  from  the  research  conducted  to  date  have  indi¬ 
cated  that  run-time  estimates  are  a  viable  option  for 
improving  scheduling  decisions  [Abb89,  Abb92,  Kim93, 
Son91].  The  fact  that  critical  information  such  as  run¬ 
time  costs  can  improve  scheduling  decisions  and  subse¬ 
quently  overall  system  performance  is  quite  intuitive. 
However,  the  derivation  of  run-time  estimates  is  not 
straightforward,  and  have  typically  been  derived  from 
simulation  models.  The  derivation  and  use  of  run-time 
estimates  in  a  functional  real-time  database  system  has 
not  been  appropriately  explored. 

One  of  the  goals  in  the  design  of  MRDB  was  to 
derive  credible  run-time  estimates  and  to  integrate  those 
estimates  in  scheduling  decisions.  The  approach  we 
used  was  to  exploit  the  physical  characteristics  of  the 
data  (such  as  attribute  types,  number  of  attributes  in  a 
relation,  and  the  numbers  of  tuples  in  a  relation)  being 
manipulated,  along  with  the  type  of  database  operation 
being  performed  (such  as  union,  set  difference  and 
project),  in  an  attempt  to  derive  credible  run-time  esti¬ 
mates.  While  the  arrival  and  types  of  transactions  enter¬ 
ing  the  system  and  the  data  which  they  access  may  be 
random,  the  computation  steps  involved  in  providing  the 
appropriate  response  are  not  unpredictable.  The  steps 
required  to  execute  any  MRDB  command  is  static  in 
nature,  and  in  a  simplified  outlook,  only  the  number  of 
iterations  involved  is  dynamic. 


The  dynamic  nature  of  the  computation  is  depen¬ 
dent  on  the  number  and  types  of  attributes  involved, 
along  with  the  number  of  tuples  which  constitute  a  rela¬ 
tion.  For  example,  the  run-time  cost  for  selecting  values 
from  a  relation  consisting  of  only  a  single  tuple  is  mini¬ 
mal.  It  consists  of  basic  start-up  costs  (such  as  transmit¬ 
ting  the  command,  preprocessing,  opening  of  relations, 
and  reading  in  the  data  from  disk),  the  actual  computa¬ 
tion  cost  in  selecting  that  single  value,  and  basic  termi¬ 
nating  operations  (such  as  providing  the  transaction 
results).  The  run-time  cost  for  selecting  the  same  set  of 
values  from  a  relation  of  five  hundred  tuples  entails  the 
same  basic  costs  associated  with  opening  and  closing 
operations  for  a  single  tuple  relation,  only  the  computa¬ 
tion  costs  increase  in  relation  to  the  number  of  tuples  that 
have  to  be  processed. 

Other  factors  such  as  system  load  and  data  con¬ 
flicts  do  not  affect  the  run-time  costs  associated  with  a 
given  transaction.  Such  factors  only  increase  the  compe¬ 
tition  for  system  resources,  such  as  the  CPU  and  IO 
access.  For  example,  given  the  cost  for  selecting  values 
from  a  given  relation  is  ‘2’  time  units.  If  half  that  time  is 
consumed,  and  that  select  operation  is  subsequently 
blocked  by  a  higher  priority  transaction  whether  it  be  for 
CPU  or  data  contention  reasons,  it  will  still  require  ‘1’ 
time  unit  to  complete  once  it  becomes  unblocked. 

With  this  approach,  we  ran  numerous  perfor¬ 
mance  measurements  tests  to  capture  the  run-time  costs. 
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The  results  indicate  that  viable  run-time  estimates  could 
be  derived  based  on  the  physical  characteristics  of  the 
data  being  manipulated  and  the  operation  being  per¬ 
formed.  The  results  which  follow  are  a  small  extract 
from  those  numerous  run-time  cost  analysis  experi¬ 
ments.  The  results  are  based  on  database  operations  per¬ 
formed  on  relations  of  the  format  displayed  in  Figure  2. 
This  relation  represents  the  track  data  generated  by  the 
Interim  Battle  Group  Tactical  Trainer,  for  an  outer  air 
battle  scenario  being  used  at  the  Naval  Ocean  Systems 
Center  [But90]. 


4.3.  Performance  Results 

The  results  of  run-time  estimate  performance 
measurements  for  four  basic  MRDB  commands  (project, 
select,  union,  set  difference)  operating  on  relations  dis¬ 
played  in  Figure  2  are  given  in  Figure  3,  and  graphically 
displayed  in  Figure  4.  The  x-axis  of  Figure  4  is  the  total 
number  of  tuples  processed  by  the  operation.  The  y-axis 
is  the  total  elapsed  time  from  the  start  of  the  operation 
until  the  final  result  is  received  at  the  client  node.  The 
performance  measurements  were  conducted  in  an 
attempt  to  isolate  the  cost  factors  attributable  to  the  oper¬ 
ations  performed,  and  the  size  of  the  data  processed 
(measured  by  the  number  of  tuples  in  the  relations).  The 
operations  were  initiated  from  a  separate  client  node, 
transmitted  to  the  server  node,  and  the  appropriate  results 
returned  back  to  the  client.  The  run-time  costs  account 
for  activities  from  the  initiation  of  the  operation  to  the 
receipt  of  the  appropriate  result.  The  results  shown  are 
based  on  200  performance  measurements  for  each  of  the 
operations  and  relation  sizes  shown.  The  large  sample 
measurement  size  was  required  to  validate  the  results 
produced. 

The  results  show  that  the  project  and  select  oper¬ 
ation  run-time  costs  grow  in  a  linear  fashion  in  relation 
to  the  size  of  the  data  being  processed.  The  union  and  set 
difference  operations  run-time  costs  grow  exponentially 


in  relation  to  the  size  of  the  data  being  processed.  The 
run-time  cost  is  the  mean  of  the  200  performance  mea¬ 
surements.  There  was  minimal  deviation  between  the 
mean  run-time  cost  and  the  performance  measurements 
used  in  deriving  the  mean,  usually  with  90%  of  the  per¬ 
formance  measurements  falling  within  ±10%  of  the 
mean.  The  deviation  which  did  occur  between  measure¬ 
ments  can  be  attributed  to  the  limited  clock  granularity  of 
the  hardware  involved,  and  to  unpredictable  behavior  of 
the  underlying  operating  system. 

Our  run-time  cost  results  did  show  that  run-time 
estimates  could  be  derived  not  only  based  on  the  data¬ 
base  operation  being  performed  and  relation  size,  but 
also  on  the  number  and  types  of  attributes  which  make¬ 
up  relations.  However,  the  results  also  showed  that  such 
derived  run-time  estimates  were  heuristic  in  nature,  and 
that  no  guarantee  could  be  made  that  a  given  transac¬ 
tion’s  actual  run-time  cost  would  be  as  estimated.  One  of 
the  primary  contributing  factors  was  the  support  of  the 
underlying  operating  system.  However,  it  is  still  possi¬ 
ble  to  establish  functions  which  generate  acceptably 
accurate  run-time  estimates  based  on  the  physical  char¬ 
acteristics  of  the  data  and  the  operations  being  executed, 
and  that  is  what  is  implemented  in  the  MRDB  system. 

The  MRDB  system  maintains  data  on  the  physical 
characteristics  of  the  relations  in  the  database.  When  the 
scheduler  is  invoked  it  extracts  the  physical  characteris¬ 
tics  data  for  the  relations  being  processed  by  a  given 
transaction.  This  information  is  used  in  conjunction  with 
the  operation  being  performed  to  derive  a  run-time  esti¬ 
mate.  The  run-time  estimate  is  subsequently  used  in  sys¬ 
tem  scheduling  decisions.  An  extract  of  system 
performance  measurements  conducted  to  verify  that  sys¬ 
tem  generated  run-time  estimates  closely  approximated 
actual  run-time  costs  is  given  in  Figure  5.  The  solid  lines 
show  the  system  generated  run-time  estimate  for  the 
aggregate  operations  avg  max ,  and  sum.  The  dashed 
lines  show  the  actual  run-time  costs  for  those  operations 
based  on  200  performance  measurements.  The  system 
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Figure  5.  Run-time  estimates  versus  actual  cost 
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estimate  closely  approximates  the  actual  cost. 

While  no  guarantee  can  be  made  for  a  given  trans¬ 
action,  it  is  possible  to  state  that  a  given  percentage  of 
transactions  can  complete  within  the  run-time  estimate 
generated  by  the  system.  Additionally,  it  can  be  stated 
that  the  run-time  estimates  generated  will  be  within  a 
given  percentage  of  the  actual  run-time  costs.  For  exam¬ 
ple,  raising  the  system  generated  run-time  estimates  by 
10%  resulted  in  approximately  90%  of  the  transactions 
accepted  for  processing  by  MRDB  having  actual  run¬ 
time  costs  within  the  system  generated  values.  The 
down-side  of  raising  the  estimate  is  that  some  transac¬ 
tions,  whose  actual  run-time  cost  is  below  the  system 
generated  estimate,  may  be  needlessly  aborted.  The  per¬ 
centage  of  these  depends  on  the  tightness  of  the  temporal 
deadlines  attached  to  the  transactions. 


5.  Conclusions 

A  real-time  database  manager  is  one  of  the  critical 
components  of  real-time  systems,  in  which  tasks  are 
associated  with  deadlines  and  a  significant  portion  of 
data  is  highly  perishable  in  the  sense  that  it  has  value  to 
the  system  only  if  it  is  used  quickly.  To  satisfy  the  timing 
requirements,  transactions  must  be  scheduled  consider¬ 
ing  not  only  the  consistency  requirements  but  also  their 
temporal  constraints.  In  addition,  the  system  should  be 
predictable,  such  that  the  possibility  of  missing  a  dead¬ 
line  for  a  given  transaction  can  be  determined  prior  to  the 
execution  of  that  transaction  or  before  that  transaction’s 
deadline  expires. 

In  this  paper,  we  have  presented  a  relational  data¬ 
base  manager  which  possesses  temporal  functionality, 
developed  for  investigating  real-time  database  issues. 
Since  the  characteristics  of  a  real-time  database  manager 
are  distinct  from  conventional  database  managers,  there 
are  different  issues  to  be  considered  in  developing  a  real¬ 
time  database  manager.  For  example,  the  use  of  run-time 
estimates  in  scheduling  policies,  and  the  ability  to  place 
temporal  consistency  constraints  on  database  operations 
are  important  in  real-time  databases.  MRDB  was 
designed  with  the  goal  of  providing  an  operational  plat¬ 
form  for  conducting  research  on  real-time  database 
issues.  Previous  studies  using  simulated  environments 
have  provided  valuable  information  with  respect  to  real¬ 
time  database  issues.  However,  performance  results  in 
some  of  the  simulated  studies  are  sometimes  contradic¬ 
tory  with  each  other  since  they  made  different  assump¬ 
tions  about  system  environments  [Lee94].  We  believe 
that  an  operational  environment  for  investigating  real¬ 
time  database  issues  will  eliminate  some  of  the  problems 
associated  with  simulated  systems  and  provide  valuable 
and  applicable  insights  to  real-time  database  issues. 

The  MRDB  system  is  completely  functional.  The 
foundation  now  exists  for  studying  real-time  database 
issues  in  an  operational  environment.  The  results 
achieved  in  deriving  and  applying  heuristic  run-time 
estimates  and  the  ability  to  attach  temporal  consistency 
specifications  are  promising.  However,  as  with  any 
active  systems  research  projects,  there  remains  many 
technical  issues  associated  with  real-time  database  man¬ 
agement  that  need  further  investigation.  It  is  our  goal  to 


facilitate  further  development  in  this  area.  To  that  end  we 
have  oriented  our  work  effort  toward  integrating  and 
analyzing  various  conflict  resolution  mechanisms,  to 
include  optimistic  concurrency  control  mechanisms 
based  on  the  notion  of  dynamic  adjustment  of  serializa¬ 
tion  order  [Son92,  Lee93].  We  also  plan  to  extend  the 
system  to  a  distributed  environment,  capture  system  per¬ 
formance  measurements,  and  improve  the  temporal 
functionality. 
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